Benefits of Using DSOs

• DSOs minimize overall memory usage because code is shared. Two executables that use the same DSO and that run simultaneously have only one copy of the instruction from the shared component loaded into memory. For example, if executable A and executable B both link with the same DSO C, and if A and B are both running at the same time, the total memory used is what's required for A, B, and C, plus some small overhead. If C was an unshared library, the memory used would be what's required for A, B, and two copies of C.

• Executables linked with DSOs are smaller than those linked with unshared libraries because the shared objects aren't part of the executable file image, so disk usage is minimized.

• DSOs are much easier to use, build, and debug than static shared libraries. Most of the libraries supplied by Silicon Graphics are available as DSOs. In the past, only a few static shared libraries have been available; most libraries were unshared.

• Executables that use a DSO don't have to be relinked if the DSO changes; when the new DSO is installed, the executable automatically starts using it. This feature makes it easier to update end users with new software versions. It also allows you to create hardware-independent software packages more easily.

  Suppose, for example, you want to build both MipsIV and a MipsIII versions of a shared object. You want your program to use the MipsIV version when it is running on a Power Challenge (R8000) system, and also run correctly on another 64-bit platform. Suppose you want to do the above with the routines in as library named libchange.so. To do this, build one version of the routines in libchange using the -mips4 option, and place it in /usr/lib64/mips4 on a Power Challenge system. Next, build another version using the -mips3 option, and place it in /usr/lib64. Then, when you build an executable that uses libchange, use the -rpath option to tell the run-time linker to look first for MipsIV versions of the libraries. For example:

  cc -mips3 -o prog prog.o -rpath /usr/lib64/mips4 -lchange

  As a result, prog runs on any IRIX 6.0 system, and it automatically takes advantage of any MipsIV libraries whenever it runs on a Power Challenge system.

• DSOs and the executables that use them are mapped into memory by a run-time loader, rld, which resolves external references between objects and relocates objects at run time. (DSOs contain only position-independent code [PIC], so they can be loaded at any virtual address at run time.) With rld, the binding of symbols can be changed at run time at the request of the executing program. You could use this feature to dynamically change the feature set presented to a user of your application, for example, while minimizing start-up time. The application could be started quickly, with a subset of the features available and then, if the user needs other features, those can be loaded in under programmatic control.